Building control systems are systems that are employed to regulate and control various environmental and safety aspects of commercial, industrial and residential facilities (hereinafter referred to as “buildings”). In ordinary single-family residences, control systems tend to be simple and largely unintegrated. However, in large buildings, building control systems often consist of multiple, integrated subsystems employing hundreds of elements.
One example of a building control system is a heating, ventilation and air-conditioning (“HVAC”) building control system. An HVAC system of a large building or building complex operates in part by interrelating small, local control loops with larger control loops to coordinate the delivery of heat, vented air, and chilled air to various locations throughout the building. Local control systems may, among other things, open and close vents that supply heated or chilled air based on local room temperature readings. Larger control loops may, among other things, obtain many distributed temperature readings and/or air flow readings to control the speed of a ventilation fan, or control the operation of heating or chilling equipment.
As a consequence of the interrelationship of these control loops, many elements of a building control system must communicate information to each other. To this end, communication networks have been incorporated that transmit digital data between and among the various elements in accordance with one or more sets of protocols.
Some of the elements of a sophisticated building control system that can communicate information include field controller devices, supervisory control stations, sensors and actuators. Sensors and actuators are the terminal devices of the building control system. Sensors measure and/or collect raw data regarding the system, and actuators physically change the output of the system. Sensors may include temperature sensors, humidity sensors, air flow sensors and the like. Actuators may include devices that alter fan speed, alter the position of ventilation shaft dampers, or alter the flow of hot water through heating pipes. Field controller devices may be used to control localized portions of the system, while supervisory control stations provide overall control and monitoring of the entire system, or at least large parts of the system.
Other types of building control systems, for example, fire safety and security systems, also include distributed actuators and/or sensors as well as field controllers and supervisory control stations.
One desirable feature of control systems is the ability to access system-wide data from many diverse elements at the supervisory control station. Such system-wide data may include, for example, room temperatures, water valve positions, and air flow values. Such information allows the supervisory control station to monitor sensed conditions, track maintenance conditions of devices, monitor alarm conditions and so forth. Such system-wide access is provided via the communication network of the building control system.
By way of example, the APOGEE™ brand of building automation system available from Siemens Building Technologies, Inc. of Buffalo Grove, Ill. employs a multi-tier network to facilitate communication of data to and from centralized supervisory control stations. The supervisory control station used in an APOGEE™ system is an INSIGHT™ work station, also available from Siemens Building Technologies, Inc. The INSIGHT™ work station uses Ethernet networks and various communication protocols to perform communications with field controllers and the like. Field controllers and other intermediary devices may further connect to other devices (e.g. actuators and sensors) via floor-level networks. Ideally, the supervisory control station may access system data from systems devices on the floor-level networks via the field controllers and/or other intermediary devices.
One issue that arises in building control system communication networks is the cohesive handling of communication messages in a timely manner. Various applications in a supervisory control station may require multiple communications with various remote devices in short periods of time. Such communications are carried out via messages transmitted over the building communication network.
One typical building control system communication message consists of a query by a supervisory control station to another device, requesting a response. The response may merely be an acknowledgement, or may also include data requested in the query, such as a temperature value, or valve position value. Because communication networks for large building control systems can become large and vast, there is a possibility for message communication to be delayed. When messages are delayed, a query from a supervisory control message can be left open (i.e. without answer) for an extended period of time. As is known in the building control system field, an open query to another remote device monopolizes resources and reduces the capacity for one or more devices to service other communication needs. Accordingly, an open query that is held open indefinitely due to a communication error can reduce the responsiveness of a building control system.
To address these issues, certain communication systems employ time-out procedures that limit the amount of time a query message may be left open. If an answer to a query message is not received within a predefined time, then the querying device releases the query/request and no longer uses system resources to await a response. The querying device may generate another query/request, or abandon the operation altogether.
One communication module currently used in building control systems is the BACstac™ module, a software module that implements the BACnet open protocol to effectuate communications between centralized control systems and various control system devices. BACstac™ is a product name of Cimetrics, Inc., located in Boston, Mass. This BACstac™ module receives requests from an application within a building system workstation or control station and formulates an appropriate data request in the BACnet protocol. The BACstac™ module then transmits the request over the communication network (via a physical layer communication interface) to the appropriate device and awaits a return message. If a return message including a response to the query is received by the BACstac™ module, then the BACstac™ module provides the data to the application within the control station or workstation that formulated the request.
However, if a return message is not received within a time-out limit, then the BACstac™ module abandons the open query and informs the building system workstation application that a response has not been timely received. The building system workstation application may then handle the error in an appropriate manner, including possibly forming another request for the data. In any event, the building system application and the BACstac™ module resources are not forced to await indefinitely for the response to the original request.
While the above system reduces problems with the unavailability of system resources due to delayed or failed communication messages, there can be problems related to too many messages being canceled due to delay, such that applications will not obtain the data they require. There also can remain system resource allocation issues even with the time-out features.
As a consequence, there is a need for system and method that can alleviate problems associated with communication delays in a building control system that balances the need for allowing system resources to be released from processes involving lost or delayed communication messages and the need to allow for delays in communications.